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EXAMINER'S ANSWER 



This is in response to the appeal brief filed 6 April 2006 appealing from the Office action 
mailed 18 May 2005. 



(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief 

(2) Related Appeals and Interferences 

The following are the related appeals, interferences, and judicial proceedings 
known to the examiner which may be related to, directly affect or be directly affected by 
or have a bearing on the Board's decision in the pending appeal: 

Application No. 09/73 1,088 is cited in the specification on page 4 Hne 15-22 as 
being incorporated by reference. The examiner's rejection was appealed to the Board of 
Patent Appeals and Interferences (Appeal No. 2005-1783) and a decision was mailed on 
12 August 2005. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

No amendment after final has been filed. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 



The appellant's statement of the grounds of rejection to be reviewed on appeal is 

correct. 



(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

2002/0046248 Al Drexter 4-2002 

5,870,761 Demers et al. 2-1999 

6,704,742 B 1 Huth et al. 3-2004 

6,658,426 Bl Poskanzer 12-2003 

(9) Grounds of Rejection 

The following ground(s) of rejection are appHcable to the appealed claims: 

Claims 1-5, 10-12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 52-58, 64-65, and 
67-90 are rejected under 35 U.S.C. 102(e) as being anticipated by Drexter (U.S. patent 
appUcation publication No. 2002/0046248 Al). 

As to claim 1, Drexter teaches a method for converting messaging data into a 
relational table format in a database system, wherein the messaging data is within a 
messaging system (see page 1, paragraph 0002), the method comprising the steps of 

(a) providing a plurality of table formatting specifications; (see page 2, paragraph 

0029); 



(b) utilizing the plurality of table formatting specifications to automatically build 
and store a table function in the database system (see page 3, paragraph 0034, where it is 
inherent that the associations (functions) are stored if they are going to be retrieved or 
recalled); 

(c) invoking the table function to access the messaging data (see pages 2-3, 
paragraphs 0030-0033); and 

(d) converting the messaging data by the table function into specific data types 
according to the plurality of table formatting specifications, wherein the messaging data 
is transformed into the relational table format (see page 3, paragraph 0033). 

As to claim 27, Drexter teaches a computer readable medium containing 
programming instructions for converting messaging data into a relational table format in 
a database system, wherein the messaging data is within a messaging system (see page 2, 
paragraph 0024), comprising the programming instructions for: 

(a) providing a plurality of table formatting specifications (see page 2, paragraph 

0029); 

(b) utilizing the plurality of table formatting specifications to automatically build 
and store a table function in the database system (see page 3, paragraph 0034, where it is 
inherent that the associations (functions) are stored if they are going to be retrieved or 
recalled); 

(c) invoking the table function from within the database system to access the 
messaging data (see pages 2-3, paragraphs 0030-0033); and 



(d) converting the messaging data by the table function into specific data types 
according to the plurality of table formatting specifications, wherein the messaging data 
is transformed into the relational table format (see page 3, paragraph 0033). 

As to claims 2 and 28, Drexter teaches wherein the table function invokes at least 
one messaging function within the database system (see page 4, paragraph 0042). 

As to claims 3 and 29, Drexter teaches wherein the table function and the at least 
one messaging function are user-defined functions within the database system (see page 
3, paragraph 0034). 

As to claims 4 and 30, Drexter teaches wherein the at least one messaging 
function retrieves and reads messaging data in the message system (see page 4, paragraph 
0042). 

As to claims 5 and 31, Drexter teaches wherein the providing step (a) ftirther 
includes the step of: 

(al) reading the plurality of table formatting specifications from a file (see page 4, 
paragraph 0041). 

As to claims 10 and 36, Drexter teaches wherein the providing step (a) further 
includes the step of: 



(al) providing formatting information about the messaging data (see pages 2-3, 
paragraphs 0030-0033). 

As to claims 1 1 and 37, Drexter teaches wherein the providing step (al) further 
includes the steps of 

(ali) designating a deUmiter character, wherein the delimiter character separates 
the messaging data into column data (see pages 2-3, paragraphs 0030-0031). 

As to claims 12 and 38, Drexter teaches wherein the converting step (d) further 
comprising: 

(dl) invoking a parser function within the database system for parsing the 
deUmited messaging data (see pages 2-3, paragraphs 0030-0031). 

As to claims 14 and 40, Drexter teaches wherein the providing step (al) further 
includes the step of 

(ali) specifying a fixed-length format by indicating a position (see page 3, 
paragraph 0036) and length of each column (see pages 2-3, paragraph 0030). 

As to claims 15 and 41, Drexter teaches wherein the providing step (a) further 
includes the step of 

(a2) allowing a user to view the messaging data in the messaging system to verify 
the formatting information provided (see page 6, paragraph 0064). 



As to claims 16 and 42, Drexter teaches wherein the messaging data comprises a 
message string, the message string including a plurality of substrings, wherein each 
substring represents data that is returned as a column in a table (see page 3, paragraph 
0037, where "column" is read on "field"). 

As to claims 17 and 43, Drexter teaches wherein the providing step (a) further 
includes the step of: 

(al) defining a column for each substring of the plurality of substrings in the 
message string (see page 3, paragraph 0036). 

As to claims 22 and 48, Drexter teaches wherein the providing step (a) further 
includes the step of 

(al) allowing a user to create and name a table view based on the table formatting 
specifications (see page 3, paragraphs 0034-0037). 

As to claims 23 and 49, Drexter teaches wherein the invoking step (c) further 
includes the step of 

(cl) selecting messaging data from the table view (see page 3, paragraph 0036). 

As to claims 24 and 50, Drexter teaches wherein the providing step (a) further 
includes the step of 

(al) allowing a user to review a summary of the table formatting specifications 
before building the table function (see page 3, paragraph 0035-0036). 



As to claims 26 and 52, Drexter teaches further including populating directly a 
relational table in the database system with the returned messaging data (see figure 1). 

As to claim 53, Drexter teaches a system for converting messaging data into a 
relational table format in a database system, wherein the messaging data is within a 
messaging system (see page 1, paragraph 0002), the system comprising: 

a processor (see page 2, paragraph 0023); 

a table function building application executable by the processor for receiving a 
plurality of table formatting specifications (see page 2, paragraph 0029) and for utilizing 
the plurality of table formatting specifications to automatically build and store a table 
function in the database system (see page 3, paragraph 0034, where it is inherent that the 
associations (functions) are stored if they are going to be retrieved or recalled); and 

means for invoking the table function from within the database system to access 
the messaging data (see pages 2-3, paragraphs 0030-0033); 

wherein, once invoked, the table function converts the messaging data into 
specific data types according to the plurality of table formatting specifications and 
transforms the messaging data into the relational table format (see page 3, paragraph 
0033). 

As to claim 54, Drexter teaches wherein the table function invokes at least one 
messaging function within the database system (see page 3, paragraph 0038). 



As to claim 55, Drexter teaches wherein the table function and the at least one 
messaging function are user-defined fiinctions within the database system (see page 3, 
paragraph 0034). 

As to claim 56, Drexter teaches wherein the at least one messaging function 
retrieves and reads messaging data in the message system (see page 3, paragraph 0038). 

As to claim 57, Drexter teaches wherein the table function building application 
includes a means for collecting the table formatting specifications from a user (see page 
3, paragraphs 0035-0037). 

As to claim 58, Drexter teaches wherein the table function building application 
includes means for downloading the table formatting specifications from a file (see page 
3, paragraph 0034). 

As to claim 64, Drexter teaches wherein the table function building application 
builds the table function based on the plurality of table formatting specifications collected 
through the graphical user interface (see page 3, paragraphs 0035-0037). 

As to claim 65, Drexter teaches wherein the invoking means includes means for 
selecting messaging data from the table view (see page 3, paragraph 0036). 



As to claim 67, Drexter teaches a system for generating a customized invocation 
mechanism (seepage 1, paragraph 0002), comprising: 

an interface for receiving customizations (see page 3, paragraph 0034-0037); and 
a software module coupled to the interface for building an invocation mechanism 
based on the customization specifications and storing the invocation mechanism in a 
database (see page 3, paragraph 0034, where it is inherent that the associations 
(functions) are stored if they are going to be retrieved or recalled), wherein the invocation 
mechanism is invokable by the database for accessing data external to the database (see 
page 3, paragraphs 0036-0037). 

As to claim 75, Drexter teaches a method for generating a customized invocation 
mechanism (see page 1, paragraph 0002), comprising the steps of 

receiving customization specifications (see page 3, paragraphs 0034-0037); and 
building an invocation mechanism based on the customization specifications and 
storing the invocation mechanism in a database (see page 3, paragraph 0034, where it is 
inherent that the associations (functions) are stored if they are going to be retrieved or 
recalled), wherein the invocation mechanism is invokable by the database for accessing 
data external to the database (see page 3, paragraphs 0036-0037). 

As to claim 83, Drexter teaches a program product containing instructions 
executable by a computer, the instructions embodying a method for generating a 
customized invocation mechanism (see page 2, paragraph 0024), comprising the steps of 

receiving customization specifications (see page 3, paragraphs 0034-0037); and 



building an invocation mechanism based on the customization specifications and 
storing the invocation mechanism in a database (see page 3, paragraph 0034, where it is 
inherent that the associations (functions) are stored if they are going to be retrieved or 
recalled), Mrherein the invocation mechanism is invokable by the database for accessing 
data external to the database (see page 3, paragraphs 0036-0037). 

As to claim 68, 76, and 84, Drexter teaches wherein the invocation mechanism is 
dynamically generated (see page 3, paragraphs 0034-0037) 

As to claim 69, 77, and 85, Drexter teaches wherein the invocation mechanism 
further comprises at least one of the group consisting of: a UDF, a table function, a 
virtual table, a stored procedure, a trigger, a query statement, and a federated table, and 
an equivalent of any of the foregoing (see page 3, paragraphs 0034-0037). 

As to claim 70, 78, and 86, Drexter teaches further comprising means for 
invoking the invocation mechanism from a database (see pages 6-7, paragraphs 0070- 
0072). 

As to claim 71, 79, and 87, Drexter teaches further comprising means for 
converting data accessed by the invocation mechanism into a format understood by the 
database (see page 5, paragraphs 0055-0057). 



As to claim 72, 80, and 88, Drexter teaches wherein the interface further 
comprising a graphical user interface for receiving function customization specifications 
(see page 7, paragraphs 0074-0077). 

As to claim 73, 81, and 89, Drexter teaches wherein the customization 
specifications further comprise specification of a relational format for nonrelational data 
accessed by the customized function (see page 3, paragraphs 0034-0037). 

As to claim 74, 82, and 90, Drexter teaches wherein the interface further 
comprises means for previewing nonrelational data in relational format based on 
customization specifications (see page 3, paragraph 0034-0037). 

Claims 6-9, 32-35, and 59-63 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Drexter (U.S. patent application publication No. 2002/0046248 Al) in 
view of Demers et al. (U.S. patent No. 5,870,761). 

As to claims 6 and 32, Drexter teaches wherein the providing step (a) further 
includes the steps of 

(al) selecting a name for the table function (see page 3, paragraph 0034); 

(a2) specifying where the table function is to be stored (see page 3, paragraph 
0034 and see page 4, paragraph 0041). 

(a3) indicating where the messaging data resides (see page 3, paragraph 0038). 



Drexter does not teach selecting a type for the table function, wherein the type 
includes one of a retrieve function and a read function. 

Demers et al. teaches duplicating at a destination site changes made to data at a 
source site (see abstract), in which he teaches selecting a type for the table function, 
wherein the type includes one of a retrieve function and a read fiinction (see column 5, 
lines 4-12). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include selecting a type 
for the table function, wherein the type includes one of a retrieve function and a read 
function. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Demers et al. 
because selecting a type for the table function, wherein the type includes one of a retrieve 
function and a read function would allow other destination sites to dequeue the record 
(see Demers et al , column 5, lines 4-12), 

As to claims 7 and 33, Drexter as modified, teaches wherein the specifying step 
(a2) further includes the steps of 

(a2i) providing a database name and access information; and (a2ii) allowing the 
user to vaUdate the access information (see Drexter . page 4, paragraph 0039). 

As to claims 8 and 34, Drexter as modified, teaches wherein the indicating step 
(a3) further includes the step of 



(a3i) providing a service point name for the messaging data (see Drexter . page 3, 
paragraph 0038). 

As to claims 9 and 35, Drexter as modified, teaches wherein the indicating step 
(a3) further includes the step of: 

(a3i) providing a system default endpoint for the messaging data (see Drexter . 
page 3, paragraph 0037). 

As to claim 59, Drexter teaches wherein the collecting means comprises a 
graphical user interface, wherein the graphical user interface prompts a user to select a 
name to specify where the table function is to be stored, and to indicate where the 
messaging data resides (see page 3, paragraph 0034). 

Drexter does not teach to select a type for the table function, wherein the type 
includes one of a retrieve function and a read function. 

Demers et al. teaches to select a type for the table function, wherein the type 
includes one of a retrieve function and a read function (see column 5, lines 4-12). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include to select a type 
for the table function, wherein the type includes one of a retrieve function and a read 
function. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Demers et al. 
because to select a type for the table function, wherein the type includes one of a retrieve 



function and a read function would allow other destination sites to dequeue the record 
(see Demers et al.. column 5, lines 4-12). 

As to claim 60, Drexter as modified, teaches wherein the graphical user interface 
further prompts the user to provide formatting information about the messaging data (see 
Drexter. page 3, paragraphs 0035-0036). 

As to claim 61, Drexter as modified, teaches wherein the messaging data 
comprises a message string, the message string including a plurality of substrings, 
wherein each substring represents data that is returned as a column in a table (see 
Drexter , page 3, paragraph 0036). 

As to claim 62, Drexter as modified, teaches wherein the graphical user interface 
further allows the user to define a column for each substring of the plurality of substrings 
in the message string (see Drexter . page 3, paragraph 0035-0037). 

As to claim 63, Drexter as modified, teaches wherein the table function building 
application builds the table function based on the plurality of table formatting 
specifications collected through the graphical user interface (see Drexter. page 3, 
paragraph 0035-0037). 



Claims 13 and 39 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Drexter (U.S. patent application publication No. 2002/0046248 Al) in view of Huth et al. 
(U.S. patent No. 6,704,742 Bl). 

As to claims 13 and 39, Drexter teaches wherein the invoking step (dl) further 
includes: 

(dli) checking for the parser function within the database system (see figure 2, 
reference number 42); and 

(dliii) registering the parser function to the database system after it is built (see 
page 3, paragraph 0036). 

Drexter does not teach 

(dlii) building the parser function if it does not exist within the database system. 

Huth et al. teaches accessing database data so that massive amounts of data can be 
manipulated in many different ways to generate reports of many different types in a rapid 
manner (see abstract), in which he teaches building the parser function if it does not exist 
within the database system (see column 9, lines 30-58). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include building the 
parser function if it does not exist within the database system. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Huth et al. because 
building the parser function if it does not exist within the database system would allow 



the manipulation of data in a way that was not previously defined (see Huth et al. . 
abstract). 

Claims 18-21, 25, 44-47, 51, and 66 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Drexter (U.S. patent application publication No. 2002/0046248 Al) in 
view of Poskanzer (U.S. patent No. 6,658,426 Bl). 

As to claims 18 and 44, Drexter teaches wherein the defining step (al) ftirther 
includes the steps of 

(ali) naming each column (see page 5, paragraph 0056) 

Drexter does not teach (alii) designating a data type for each column. 

Poskanzer teaches designating a data type for each column (see column 3, lines 

39-43). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include designating a data 
type for each column. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Poskanzer because 
designating a data type for each column would determine how the SQL statement must be 
structured to access data relating to that field (see Poskanzen column 3, lines 39-43). 

As to claims 19 and 45, Drexter as modified, teaches wherein the defining step 
(al) further includes the step of 



(aliii) allowing the user to view the messaging data formatted according to the 
column definitions provided (see Drexten page 3, paragraph 0035). 

As to claims 20 and 46, Drexter as modified, teaches wherein the providing step 
(a) further includes the step of: 

(a2) building the table function based on the table formatting specifications 
collected from the user (see Drexter . page 3, paragraph 0035-0037). 

As to claims 21 and 47, Drexter as modified, teaches wherein the converting step 
(c) further includes: 

(dl) parsing the message string into the plurality of substrings (see Drexter , page 
5, paragraph 0056). 

(d2) converting each substring into the designated data type corresponding to its 
column (see Poskanzer . column 3, line 54 through column 4, line 4). 

As to claims 25 and 51, Drexter does not teach wherein the invoking step (c) 
further includes the step of: 

(cl) integrating the table function within a structured query language statement. 

Poskanzer teaches wherein the invoking step (c) further includes the step of 
integrating the table function within a structured query language statement (see column 3, 
lines 26-43). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include wherein the 



invoking step (c) further includes the step of: integrating the table function within a 
structured query language statement. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Poskanzer because 
wherein the invoking step (c) further includes the step of: integrating the table function 
within a structured query language statement would allow it to input data into an SQL 
database (see Poskanzer . column 3, lines 29-34, and see lines 15-17). 

As to clauB 66, Drexter does not teach wherein the invoking means includes 
means for integrating the table function within a structured query language statement. 

Poskanzer teaches wherein the invoking means includes means for integrating the 
table function within a structured query language statement (see column 3, lines 26-43). 

Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to have modified Drexter to include wherein the 
invoking means includes means for integrating the table function within a structured 
query language statement. 

It would have been obvious to a person having ordinary skill in the art at the time 
the invention was made to have modified Drexter by the teachings of Poskanzer because 
wherein the invoking means includes means for integrating the table function within a 
structured query language statement would allow it to input data into an SQL database 
(see Poskanzer. column 3, lines 29-34, and see lines 15-17). 



(10) Response to Argument 



A - Summary of Applied Rejections 

Part A of Appellant's arguments states the grounds of the rejection given by the 
examiner and reiterates the rejection applied by the examiner to claims 1 and 67. Part A 
also reiterates some of a response given by the examiner in the final action. No specific 
arguments from Appellant are given in this section. 

B - The Cited Prior Art 

Part B of Appellant's arguments gives a short summary of sections of the applied 
references that Appellant feels are relevant. No specific arguments from Appellant are 
given in this section. 

C - Claims 1-5, 10-12, 14-17, 22-24, 26-31, 36-38, 40-43, 48-50, 52-58, 64-65, 
and 67-90 

In response to Appellant's arguments that "Drexler does not teach or suggest 
storing 'a table function in the database system,' ... or 'storing the invocation mechanism 
in a database'", the arguments have been folly considered but are not deemed persuasive. 
Appellant's arguments seem to be directed towards what a reasonable interpretation for a 
database system is. Appellant states "database or database system (the terms are 
interchangeable)." A database system is the entire system used in the storage and 
organization of data. Strictly speaking a database is an organized body of information 
(see http://wordnet.princeton.edu/perl/webwn?s=database). Appellant uses two 
definitions of database in his brief It is noted that "wikipedia.com" a source of one of 
the definitions is a site that can be edited by those that use the site. Because the users of 



the site can change the definitions given, the definitions are not necessarily accurate and 

adapt over time. It is also noted that wikipediaxom has broader definitions for the term 

database, including, 

A database is an organized collection of data. The term originated within the 
computer industry, but its meaning has been broadened by popular use, to the 
extent that the European Database Directive (which creates intellectual property 
rights for databases) includes non-electronic databases within its definition. This 
article is confined to a more technical use of the term; though even amongst 
computing professionals, some attach a much wider meaning to the word than 
others. 

This was the first paragraph in the definition given on wikipedia.com on the day of the 
submission of Appellant's latest brief 

Further, it is put forth that a "database system" and a "database management 
system" (DBMS) do not have the same meaning. While DBMS is most often used to 
describe the software (application) side of a database/database system, a 
database/database system is used to describe the whole of the system including the data 
being stored, the instructions that are used to perform operations on the data, the 
hardware used to store the data, the hardware used to store the functions that operate on 
the data, and the hardware used in invoking these fimctions. All these components work 
together to create a system that can store data in an organized fashion. 

Appellant argues that it is "not reasonable" for the definition of a database system 
to include the hardware that runs the database management system software and holds the 
database data. This then raises the question would the statement "the hard drive in my 
database has malfiinctioned" or the statement "I upgraded the processor in my database 
system" be unreasonable statements? 



Also, the "Email to Database Import Program" of Drexler (figure 1, reference 
number 40) is the program used to interact with the data that is stored in the tables of 
Drexler' s database. So the "Email to Database Import Program" is the DBMS software 
that Appellant beUeves is required by the claim, and hence fits as part of the database 
even given Appellant's definition of a database. Since the associations used by the 
program in Drexler reference can be found "in memory files such as those on a floppy 
diskette, on the computers hard drive, or a network hard drive" (see Drexler paragraph 
0041), these associations being part of the import program are part of the database and 
are stored in the database. 

Appellant states, "Accordingly, a separate application module is not required to 
use the table function and invocation mechanism." However, a DBMS (the software that 
is used to manage a database) is a collection of programs that enables you to store, 
modify, and extract information from a database (see 

http ://www. webopedia. com/TERM/D/database_management_sy stem_DBMS . html) . 
Since a DBMS is more than one program and used in managing the data in a database, it 
is not clear why Appellant excludes the "Email to Database Import Program" fi-om the 
DBMS. The import program extracts data and then puts it into a database (see Drexler, 
abstract). It is not clear what else a program must do to become a database management 
program. 

Appellant states "[other] files, information and data stored in the file system of the 
computer system, outside of the database/database system, are managed by the operation 
system or some other application(s) in the computer system, and not by the 
database/database system." However the program and associations of Drexler are not 



"other files" with some purpose other than the organized storage of data in a database 
table. They do not have any non-database related function so they are directly related to 
the database and are used in the management of it. 

Appellant also argues, "In the present invention, the table function can be invoked 
fi'om within the database/database system via an SQL statement." However none of the 
claims rejected under 35 U.S.C. 102(e) make any mention of SQL, and in paragraph 0027 
Drexler discusses using SQL databases. 

In response to Appellant's arguments that "nothing teaches or suggests that the 
association transforms the messaging data into the relational table format'", the 
arguments have been fully considered but are not deemed persuasive. Paragraphs 0062- 
0064 disclose the parsing of an email message and putting the email message data into 
the table 680. This table is a relational table because it is organized in rows and columns. 
Further, paragraph 0027 discloses the different databases that can be used in conjunction 
with Drexler. Microsoft Access and SQL server 2000 both use relational tables because 
they are relational databases. 

D - Dependent claims 2, 28, and 54 

In response to Appellant's arguments that "Drexler fails to teach or suggest a 
table function that 'invokes at least one messaging function from within the database 
system'", the arguments have been fully considered but are not deemed persuasive. 
Appellant's argument appears to be related to an earlier argument that the program 
disclosed in Drexler is not part of the database system. Paragraph 0042 does clearly 



disclose a messaging function that retrieves the data from the email Since this function 
is a part of the Email to Database Import Program, if the program is found to be part of 
the database, this limitation is fiilly disclosed by Drexler. 

E - Dependent claims 3, 29, and 55 

In response to Appellant arguments that "Drexler fails to teach or suggest that the 
table function and the messaging function 'are user-defined functions within the database 
system'", the arguments have been fully considered but are not deemed persuasive. 
Paragraph 0034 discloses the user defining the associations that are used when importing 
data into the database from an email message. The association that is created is a 
function that is later used by the program to retrieve data from an email at a later time. 
Appellant states "there is not teaching or suggest in paragraph 0034 that the messaging 
function ... is also a UDF within the database system". Although the messaging function 
is not directly disclosed as being a UDF in paragraph 0034, it is disclosed in paragraph 
0042 where the user can "enable automated data import by the association, and another 
input location may include the time period between new email checks" i.e., the user can 
define if and when the email importation is automatically done. 

F. - Dependent claims 6-9, 32-35, and 59-63 
No new arguments directed towards claims 6-9, 32-35, and 59-63 are given by Appellant. 

G - Dependent claims 13 and 39 
No new arguments directed towards claims 13 and 39 are given by Appellant. 



H - Dependent claims 18-21, 25, 44-47, 51, and 66 
No new arguments directed towards claims 18-21, 44-47, 51, and 66 are given by 
Appellant. 

(11) Related Proceeding(s) Appendix 

Copies of the court or Board decision(s) identified in the Related Appeals and 
Interferences section of this examiner's answer are provided herein. 

For the above reasons, it is believed that the rejections should be sustained. 
Respectfully submitted, 

Jacob F. Betit 
Patent Examiner 



Conferees: 





Charles Rones 

Supervisory Patent Examiner 



Hosain Alam ^ 
Supervisory Patent Examiner 



Sam Rimell 




SAMRIMEa 
PRIMARY EXAMINER 



Primary Examiner 

An appeals conference was held on 21 June 2006, and it was agreed to proceed to 
the Board of Appeals. 
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The opinion in support of the decision being entered today was not written for 
publication and is not binding precedent of the Board. 
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DECISION ON APPEAL 
This is a decision on appeal under 35 U.S.C. § 134 from the examiner's final 
rejection of claims 1-18, which are all the claims in the application. 
We affirm. 
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BACKGROUND 

The invention relates to asynchronous messaging and queuing, in particular 

integrating messaging functionality into database operations. Representative claim 1 is 

reproduced below. 

1 . A method for integrating messaging functionality into database 
operations, the method comprising: 

(a) providing one or more chosen functions from a messaging system in a 
database system; and 

(b) utilizing the one or more chosen functions from the database system 
within structured query language statements to access the messaging system 
from the database system. 

The examiner relies on the following reference: 

Chandra et al. (Chandra) 6,058,389 May 2, 2000 

(filed Oct. 31, 1997) 

Claims 1-18 stand rejected under 35 U.S.C. § 102 as being anticipated by 
Chandra. 

We refer to the Final Rejection (mailed Feb. 17, 2004) and the Examiner's 
Answer (mailed Oct. 29, 2004) for a statement of the examiner's position and to the 
Brief (filed Aug. 17. 2004) and the Reply Brief (filed Jan. 3, 2005) for appellant's 
position with respect to the claims which stand rejected. 
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OPINION 

Appellant states that the claims form one group (Brief at 5). Consistent with the 
rules in effect at the time of filing of the Brief, we select claim 1 as the representative 
claim. S§g37 CFR § 1.192(c)(7) (2004). See also In re McDaniel. 293 F.3d 1379. 
1383, 63 USPQ2d 1462, 1465 (Fed. Cir. 2002) (If the brief fails to meet either 
requirement [of 37 CFR § 1.192(c)(7)], the Board is free to select a single claim from 
each group of claims subject to a common ground of rejection as representative of all 
claims in that group and to decide the appeal of that rejection based solely on the 
selected representative claim."). 

The examiner finds claim 1 to be anticipated by Chandra (Answer at 3), 
contending that the described ENQUEUE and DEQUEUE operations are "chosen 
functions from a messaging system" as claimed. Appellant's position argued in the 
briefs does not persuade us that the finding is in error. 

We consider appellant's arguments, at least to the extent they are 
commensurate with the scope of claim 1, to be sufficiently addressed in the Answer. 
The basic disagreement is founded on appellant's premise that the claim requires a 
messaging system that is separate from the database system, contrary to the 
examiner's observation (Answer at 8) that a separate messaging system is not a 
requirement. 
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Claims are to be given their broadest reasonable interpretation during 
prosecution, and the scope of a claim cannot be narrowed by reading disclosed 
limitations into the claim. See In re IVIorris. 127 F.3d 1048, 1054, 44 USPQ2d 1023, 
1027 (Fed. Cir. 1997); InreZletz. 893 F.2d 319, 321. 13 USPQ2d 1320. 1322 (Fed. 
Cir. 1989); In re Prater. 415 F.2d 1393, 1404-05, 162 USPQ 541, 550 (CCPA 1969). 
Moreover, for a prior art reference to anticipate in terms of 35 U.S.C. § 102, every 
element of the claimed invention must be identically shown in a single reference. 
However, this is not an "ipsissimis verbis" test. In re Bond. 910 F.2d 831, 832, 15 
USPQ2d 1566, 1567 (Fed. Cir. 1990). 

Claim 1 purports a method for integrating messaging functionality into database 
operations. One or more chosen functions are provided "from a messaging system in a 
database system." The functions are utilized from the database system within SQL 
statements to access the messaging system from the database system. We find 
nothing in the claim that requires a messaging system separate from a database 
system or, conversely, anything that may preclude the messaging system from being 
contained within the database system. The language is consistent with using the 
database system to access a system within itself; i.e., the messaging system. 

We therefore sustain the rejection of claims 1-18 under 35 U.S.C. § 1 02 as 
being anticipated by Chandra. 
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CONCLUSION 

The rejection of claims 1-18 under 35 U.S.C. § 102 is affirmed. 
No time period for taking any subsequent action In connection with this appeal 
may be extended under 37 CFR § 1.136(a). §§§37 CFR § 1.136{a)(1)(iv). 



AFFIRMED 




JOSEPH L. DIXON 
Administrative Patent Judge 




HOWARD B. BUNKENSHIP 
Administrative Patent Judge 




5PBERT E.mPP\ 
Administrative Patent Judge 
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In Re Application of: Date: December 29, 2004 

Charles D. WOLFSON Confirmation No. 9367 

Serial No: 09/73 1 ,088 Group Art Unit: 2165 

Filed: December 5, 2000 Examiner: Rimell, S. 

For: INTEGRATION OF MESSAGING FUNCTIONS AND DATABASE OPERATIONS 

Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

REPLY BRIEF 

Sir: 

In response to the Examiner's Answer dated 10/29/04, Appellant presents the following 

reply. 

The Examiner's response to Appellant's arguments maintains that the cited art of the 
Chandra et al reference ("Chandra") teaches a messaging system (324 in FIG. 3) and distinct 
database system (FIG. 3) which gains access to the messaging system. Appellant respectfully 
disagrees. 

As described by Chandra with reference to FIG. 3 in col. 6, lines 14-28: 

A database application 300 comprises first and second client application programs 
301, 302 coupled to a relational database system 304. The relational database 
system 304 comprises a database server 310 stored in a volatile memory 306 of a 
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processor, such as main memory 104 of computer system 100. The database server 
310 communicates with data files 322, 324 either directly or through a database 
cache 312 interposed between a data file (such as file 324) and the database server 
310* The data files are stored in a nonvolatile memory 308, such as data storage 
device 107 of the computer system 100; each of the data files comprises a plurality 
of data blocks. For example, the data file 322 comprises data blocks 322a, 322b, 
which contain data of interest to the application programs 301, 302. 

Chandra clearly demonstrates that the element 324 cited by the Examiner is a data file in a 

relational database system that comprises a plurality of data blocks, which can store queue tables 

comprising queues and messages of queues (col. 6, lines 45-47). Appellant respectfully submits 

that there is nothing to teach or suggest that the storage of data blocks including queue tables of 

queues and messages of queues in data file 324 of the relational database system 304 is a 

messaging system itself, as argued by the Examiner. 

Further, Appellant respectfully submits that a data file has the function of storing data, as 

taught in the section of Chandra quoted hereinabove ("The data files are stored in a nonvolatile 

memory 308") and does not provide fimctions at all. Thus, Appellant respectfully submits that 

there is nothing to teach or suggest the recited provision of one or more chosen functions fi-om a 

messaging system in a database system by the teaching of a data file storing queues in cited 

element 324. 

Without teaching or suggesting the provision of one or more chosen functions firom a 
messaging system in a database system, there can be nothing to teach or suggest the recited 
utilization of the one or more chosen functions, including utilization within structured query 
language statements to access the messaging system from the database system. The Examiner 
asserts that the fimctions of ENQUEUE and DEQUEUE of Chandra are the fimctionalities that 
correspond to the recited one or more chosen functions, and are considered to be "from the 
messaging system" by reason that they are fimctions used in the messaging system. Appellant 
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respectfully disagrees and submits that these are not functions used in the messaging system. 
Rather, they are functions of the database system that are used in the database system to access 
the queue tables of the data files of the database system. See Table 3 (columns 23-24), which "is 
an example of SQL statements that may be used to command an embodiment of the invention to 
enqueue and then dequeue a single message," and which shows ENQUEUE and DEQUEUE as 
distinct commands in the SQL language as implemented in a database system. That these 
conunands result in action on a queue table that contains messages in the database system does 
not provide any teaching or suggestion that they should or could be considered to be "from the 
messaging system", as asserted by the Examiner, since they are commands of the database system 
itself to manage the data file that contains a message queue. 

In addition, the Examiner states "examiner believes that the intended meaning of the 
claim language 'fi-om a messaging system', based on applicant's specification is exactly met by 
the functionalities of ENQUEUE and DEQUEUE taught by Chandra et al. In appellant's 
specification, the chosen functionalities are functions used in a messaging system . These are 
exactly the fiinctionality implied by the terms ENQUEUE and DEQUEUE" (page 5). Appellant 
respectfully disagrees with the Examiner and points out that Appellant's specification is clear in 
the description of FIG. 1 that messaging software/a message queue manager (e.g., MQSeries) is 
running on a computer system for managing a message queue. As further disclosed by 
Appellant's specification, during messaging operations, whenever a new message destined for 
computer system Ic is received over network 2 from one of the other computer systems (e.g., la 
or lb) the message is stored in the message queue 11. The data associated with the message is 
stored in long term storage 14. When the processor 13 requests that a particular message be 
dequeued, that message's associated data is retrieved from storage 14 and provided to processor 
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13. This occurs without any teaching or suggestion of a need to utilize commands of the 
database system. Rather, as further described in the specification, the integration of messaging 
software functionality into database programming with the present invention is achieved through 
a straightforward approach that utilizes the mechanisms provided by SQL to allow a database 
queiy to be formed that incorporates messaging operations within a SQL statement. In this 
manner, the SOL statement appears in itself as an application to the messaging software . 

Thus, while the Examiner has interpreted the intended meaning of claim 1 based on the 
specification, Appellant respectfully submits that this interpretation has failed to fully consider 
the actual disclosure of the specification, which demonstrates that there is a messaging system 
(e.g., MQSeries) with its own functionality and a database system with its own functionality, and 
through the integration of functions of the messaging system in the database system, access to the 
messaging system fi-om the database system can occur, such that the SQL statement of the 
database system appears in itself as an application to the messaging software. Appellant 
respectfully submits that claims are clearly recited in the present invention and require no further 
interpretation of intended meaning. Thus, Appellant respectfully reiterates that the use of SQL 
commands to access a data file in a database system as disclosed by Chandra offers no teaching 
or suggestion of the recited invention, which includes providing one or more chosen functions 
from a messaging system in a database program and utilizing the one or more chosen functions 
fi-om the database program within structured query language statements to access the messaging 
system firom the database program. 

For the foregoing reasons, along with those reasons presented in the Appeal Brief, 
Appellant further respectfully reiterates the requeist that the Board reverse the rejection of all the 
appealed claims and find each of these claims allowable. 
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This Reply Brief is being submitted in triplicate, and the Conmiissioner is authorized to 
charge any fees associated with this communication to Deposit Account No. 09-0460 (IBM 
Corporation). 

Respectfully submitted, 
SAWYER LAW GROUP LLP 
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(1) Real Party in Interest 

A statement identifying the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

A statement identifying the related appeals and interferences which will directly affect or 
be directly affected by or have a bearing on the decision in the pending appeal is contained in the 
brief 

(3) Status of Claims 

The statement of the status of the claims contained in the brief is correct. 

(4) Status of Amendments After Final 

No amendment after final has been filed. 

(5) Summaty of Invention 

The summary of invention contained in the brief is correct, 

(6) Issues 

The appellant's statement of the issues in the brief is correct. 

(7) Grouping of Claims 

Appellant holds that the claims stand or fall together. Examiner agrees with this assertion 
and finds the brief is directed to argument for only one grouping. Claim 1 is the representative 
claim of the group. 

(8) Claims Appealed 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(9) Prior Art of Record 

U.S. Patent 6,058,389 to Chandra et al.; Published May 2, 2000; Filed October 31, 1997, 
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(10) Grounds of Rejection 

The followinjg ground(s) of rejection are applicable to the appealed claims: 
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 
A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

Claims 1-18 are rejected under 35 U.S.C. 102(e) as being anticipated by Chandra et al. 
(U.S. Patent 6,058,389). 

Claim 1: Chandra et al. sets forth a database system (overall system of FIG. 3) 
containing message queues (324 and 200). Multiple chosen functions are provided, such as 
ENQUEUE (adding a message) and DEQUEUE (removing a message) in order to control the 
messages in the message queues (See col. 12, lines 62-68; col. 13, lines 1-67; and col. 16, lines 
18-30). The ENQUEUE and DEQUEUE are functions that operate in the messaging system but 
are also implemented in the database system. The chosen functions are utilized and implemented 
within SQL statements (col. 11, lines 45-49; col. 24, Table 3). 

Claim 2: The chosen functions ENQUEUE and DEQUEUE can be added to a database 
system by creating SQL statements called ENQUEUE and DEQUEUE and parameterizng these 
statements with the parameters shown in Table 1 (col. 13, lines 1-9) and Table 2 (col. 16, lines 
25-32). The ENQUEUE and DEQUEUE functions are thus user defined functions. 

Claim 3: The user defined function ENQUEUE functions to place the message on a 
queue (col. 12, lines 60-67). The user defitied function DEQUEUE functions to non- 
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destructively retrieve .one or all of the message from the queue (col. 16, lines 18-30), The 
ENQUEUE functions also involves the function of reading the message (FIG. 9A, steps 900- 
903). 

Claim 4: The user defined function ENQUEUE function specifies a service endpoint 
(Queue Name, described at col. 13, line 5). 

Claim 5: The user defined function ENQUEUE specifies a destination (Queue Name 
described at col, 13, line 5) and delivery policies (Enqueue Options described at col. 13, line 6). 

Claim 6: The messaging system may be a publish/subscribe based messaging system 
(col. 35, lines 39-48). 

Claim 7: See remarks for claim 1. Note that the message program means are the 
messages queues shown in FIG. 2 and the database program means is the database, system of 
FIG. 3. 

Claim 8: See remarks for claim 2. 
Claim 9: See remarks for claim 3. 
Claim 10: See remarks for claim 4. 
Claim 11: See remarks for claim 5. 
Claim 12: See remarks for claim 6. 
Claim 13: See remarks for claim 1. 
Claim 14: See remarks for claim 2. 
Claim 15: See remarks for claim 3. 
Claim 16: See remarks for claim 4. 
Claim 17: See remarks for claim 5. 
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Claim 18: See remarks for claim 6. 
(11) Response to Argument 

Part A of appellant's brief is a replication of selected examiner arguments presented 
during prosecution.' No specific arguments from appellant are presented in this section. 

Part B of appellant's brief is an extremely brief summarization of certain features from 
the Chandra reference (Chandra et al.). No specific arguments are presented. 

Part C contains the main focus of appellant's arguments. Appellant first argues that 
"Appellant fails to see how a logical data structure of a queue table stored in a database file could 
be interpreted to teach or suggest a system/program means having functionality that can be 
provided in/utilized in another system" (page 7, second to last line through page 8, lines 1-2 of 
appellant's brieQ. 

The Examiner is not asserting that the message queue tables are the functionality or 
"chosen functions" set forth in claim 1. Rather, examiner is asserting that the functions of 
ENQUEUE (adding a message) and DEQUEUE (removing a message) are the fiinctionalities 
that correspond to the chosen functions in claim 1. These functions are considered to be "from 
the messaging system" by reason that they are functions used in the messaging system. These 
functions operate within an overall database system (the overall system of FIG. 3). Examiner 
maintains that the limitations of claim 1 are met. In addition, examiner believes that the intended 
"^g^"'"^ of the claim language "from a messaging system", based on applicant's specification is 
exactly met by the functionalities of ENQUEUE and DEQUEUE taught by Chandra et al. In 
appellant's specification, the chosen fiinctionalities are functions used in a messaging svstem . 
These are exactly the functionalities implied by the terms ENQUEUE and DEQUEUE, There 
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simply does not appear to be any distinction between the chosen functions and the fimctionalities 
of ENQUEUE and DEQUEUE. 

Appellant argues that the ENQUEUE and DEQUEUE are not provided by the messaging 
system, but are instead provided by programming languages, namely the C programming 
language and SQL, or Structured Query Language (page 8, second paragraph of appellant's 
brief). It is true that the ENQUEUE and DEQUEUE commands are in fact supported by an 
underlying programming language. However, this does not prevent the functions from being 
used in a message system or from a messaging system. Programming functions are inherently 
supported by programming languages. 

Appellant argues that the chosen functions ENQUEUE and DEQUEUE and not utihzed 
in SQL statements. Appellant argues that ENQUEUE and DEQUEUE are in fact SQL statements 
themselves, and thus would not be used in SQL statements (page 8, second and third paragraphs 
of appellant's brief). These arguments are not conrect. The functions ENQUEUE and DEQUEUE 
are commands that are used in larger SQL statements (col. 11, lines 45-49). ENQUEUE and 
DEQUEUE are merely the requesting portion of the SQL statement, and are used in a larger 
overall SQL statement, such as that illustrated in Table 3 (col. 24). 

Appellant argues that the claim language of claim I call for the chosen function to be 
used "within" SQL statements, not "with" SQL statements (page 8, third paragraph of 
appellant's brief). Examiner maintains that the ENQUEUE and DEQUEUE are used "within" 
SQL statements. Consider for example Table 3 at column 24 of Chandra et al. The Table is an 
example of one SQL statement. The chosen functions ENQUEUE and DEQUEUE and clearly 
within the overall statement. 
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Appellant argues that Chandra et al. fails to disclose a "separately installed messaging 
system" (page 9, first paragraph, last three lines in appellant's brief). No such feature is recited in 
claim 1, which is the claim for consideration with the single claim grouping designated by 
appellant. Furthermore, no such feature appears in independent claims 7 or 13. The closest claim 
which appears to address this feature is claim 7, which only calls for a messaging system to be 
"installed". Clearly, in Chandra et al. (FIGS. 2-3), such a messaging system is installed. 

Appellant argues that Chandra et al. does not teach the accessing of a message system 
from a database system (page 9, second paragraph of appellant's brief). This argument is 
incorrect. As seen in FIG. 3, the clients (301) and (302) are the parties that access the message 
system. The message system (message queue tables 324). are accessed via the database server, 
which is part of the database system. In Chandra et al, the message system is accessed by 
accessing the database system. This is clearly shown in FIG. 3 of Chandra et al. 

Appellant argues that examiner has not given consideration to the term "from" as it is 
used in the phrase "from a messaging system" as defined in claim 1 (page 9, last line to page 10 
first line of appellant's brieQ Examiner has given consideration and weight to this term. In 
particular, examiner concludes that the term "from a message system" means that functions 
operate on a message system or are used in a message system. This is hardly a "gross 
misinterpretation" (page 10, line 2 of appellant's brief) of the claim language presented, but 
rather a reasonable interpretation based on a literal reading of the method steps and elements 
presented. 
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Appellant presents further arguments regarding claims 3, 9 and 15 (page 10, second 
paragraph of appellant's arguments). Appellant argues that Chandra et al. lacks a separate 
messaging system accessed by a database system. However, none of the independent claims call 
for a "separate" messaging system. In addition, Chandra et al. clearly teaches a messaging 
system (324 in FIG. 3) and distinct database system (FIG. 3) which gains access to the 
messaging system. I 
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For the above reasons, it is believed that the rejections should be sustained. 

Respectfully submitted, 




Sam Rimell 
Primary Examiner 
Art Unit 2165 



October 28, 2004 
Conferees 

Safet Metjahic 
Dov Popovici 



Joseph A. Sawyer, Jr. 
Sawyer Law Group LLP 
P.O. Box 51418 



Palo Alto, CA 94303 



